1. Field of the Invention
This invention relates to computer networks, and more particularly to reputations of entities in a network.
2. Description of the Related Art
Historically, an entity in a networked computing environment may have multiple, unlinked identities that exist in centralized, disconnected repositories. Further, entity's reputations are traditionally centralized in disconnected repositories. For example, an Internet auction site or a credit-reporting agency may compute reputation scores based on information that is fed into a centralized system. This centralization may lead to a proliferation of identities, centralizes power and control in the hands of those controlling the identities, and may preclude more interesting trust relationships from forming.
An identity may be defined as a binding of attributes to a name. For example, a credit report binds a person's name to a social security number and a credit history. As another example, a Yahoo! account binds a name to a profile, an email account, and instant messaging endpoint. As yet another example, an eBay identity binds a pseudonym to a trading history and a reputation. As still yet another example, an X.509 certificate binds attributes such as a public key and an email address to a “distinguished name.” An identity may be used to consuming the attributes and information corresponding to the identity. For example, an entity may read web-based email that is associated with a pseudonym.
Establishing the identity of an entity may include several components. One component may be authentication, proving who an entity claims it is, for example to access a resource such as a peer-to-peer application or service. An authentication server may perform authentication of an entity by receiving and verifying evidence of credentials of the entity. Credentials may vary, and may include such credentials as secret handshakes, passwords, and proof of knowing a private key via public-key cryptography techniques.
Authentication may be distributed. Distributed authentication may be used to implement a “single sign-on” solution. In distributed authentication, a resource may not have to perform the authentication of an entity itself. Rather, the resource may rely on a trusted authentication service. For example, resource Y may trust a service X to perform authentication. An entity may authenticate itself to X. X may inform Y that the entity is authenticated (directly or indirectly). Thus, the entity may be authenticated to Y.
Technically, distributed authentication may be relatively easy to implement. Techniques for implementing distributed authentication are well known. However, the techniques for implementing distributed authentication are not standardized and security concerns exist for browser-based authentication services. Politically, distributed authentication is not so easy to implement. Distributed authentication requires a “trust network” of authentication services and resources that rely on the services. Presently, there is no economic impetus for such a trust network.
Another component of establishing the identity of an entity may be authorization of the entity to access a resource based on who the entity is and one or more pre-established rules. Authorization may be viewed as a step after authentication. Similar to authentication, authorization may be distributed; a relying resource may decide to trust an authorization service to perform authorization. Distributed authorization may have similar technical and political issues as distributed authentication.
Yet another component of establishing the identity of an entity may be trusted attributes. It may be necessary or desirable to establish trustworthiness of attributes associated with an entity's name. For example, one entity may tell a second entity that a third entity's public key is such-and-such. How does the second entity trust that assertion? One approach is by using certificates, for examples an X.509 certificate signed by a trusted Certificate Authority. Trust models may include, but are not limited to, Centralized, Hierarchical, and Transitive (e.g. “web of trust”) trust models. Note that trust is not necessarily binary; because one entity establishes trust in a second entity does not necessarily imply that the second entity trusts the first entity.
Still yet another component of establishing the identity of an entity may be reputation: how trustworthy is the entity in some particular context? Trust relationships for identities may be established. For example, a bank may evaluate the credit report associated with a personal physical identity. As another example, someone using eBay may make purchasing decisions based on the reputation of a pseudonym identity.
On a network of decentralized nodes, for example in a peer-to-peer networking environment, a single node may not be trusted to maintain reputation information about all the nodes. Moreover, no one node may be powerful enough to accept, verify, and store information regarding all the transactions that are taking place—information that may influence a node's reputation.
Peer-to-Peer Computing Environment
Peer-to-peer (P2P) computing, embodied by applications like Napster, Gnutella, and Freenet, has offered a compelling and intuitive way for Internet users to find and share resources directly with each other, often without requiring a central authority or server. The term peer-to-peer networking or computing (often referred to as P2P) may be applied to a wide range of technologies that greatly increase the utilization of information, bandwidth, and computing resources in the Internet. Frequently, these P2P technologies adopt a network-based computing style that neither excludes nor inherently depends on centralized control points. Apart from improving the performance of information discovery, content delivery, and information processing, such a style also can enhance the overall reliability and fault-tolerance of computing systems. FIG. 1A illustrates two peer devices 104A and 104B that are currently connected. Either of the two peer devices 104 may serve as a client of or a server to the other device. FIG. 1B illustrates several peer devices 104 connected over the network 106 in a peer group. In the peer group, any of the peer devices 104 may serve as a client of or a server to any of the other devices.